1. Field of the Invention
The present invention relates to data processing systems, and more particularly to dump analysis in such a system.
2. Background Art
When a program is executing on a data processing system, occasionally an error condition may arise which is so serious as to stop the execution of the program. Such an error, known colloquially as a system `crash`, may be connected with the system hardware, storage, or operating system, or with the program itself. The error may result directly in termination of the program (for example, a major hardware failure or programing error) or instead might cause a self-checking routine to terminate the program on the grounds that the error condition is such that the program's results are no longer reliable.
When a crash occurs, a known diagnostic routine can be used to provide detailed information relating to the state of the data processor at the time of the crash. This information, known as the `dump`, would commonly include a detailed listing of the contents and logical interrelationships of all the storage areas used by the program and/or the operating system. In the case of a large, complex program such as the IBM CICS/MVS program, the dump may be very large indeed, typically producing several hundred pages of printout. (IBM and CICS/MVS are trademarks of the International Business Machines Corporation.)
Traditionally, following a crash, an operator would manually sift through a printout of the dump, trying to discover one or more symptoms indicating the cause of the crash. Clearly, this procedure is very time-consuming and can require a large number of skilled and experienced operators. More recently, examination of the dump has been automated, in that procedural or knowledge-based dump analysis tools have been developed to examine predetermined features of the dump. These tools are based upon the operators' experience of common causes of crashes for the particular combination of programs and data processor in use.
Although dump analysis has been described above with regard to recovery and diagnostics following a system crash, it is also common for dump analysis to be performed at intervals when the system is working correctly. For example, dump analysis could be performed to assess the usage of the system storage or other resources, or to discover the number and processing requirements of the system users.
A problem arises when the program or programs in use are modified or updated. Although the dump produced when the updated program is in use may contain the same information as before, it may be expressed in a different order or in a different format. It is then necessary to rewrite at least a part of the dump analysis tool in order to access the required data from the dump. Because the analysis tools are developed based on the operators' experience with a particular data processor configuration, they are usually unique to the data processor with which they are used. Therefore the tool associated with each individual data processor must be updated whenever the programs used with that data processor are updated.
Clearly, if the tools are modified at each data processor and for each program update, there is a significant chance that the modified tools may contain programming errors. Also, it is wasteful of resources to repeat the same or very similar modifications at a large number of individual sites.